Kapitel 7 Weitere Möglichkeiten von C#

7.1 Operatorüberladung 

C# verfügt über eine Reihe von Operatoren, die Sie für allgemeine Operationen einsetzen können. Werden zwei Zahlen dividiert, müssen Sie sich keine darüber Gedanken machen, welcher Code im Hintergrund vom Compiler erzeugt wird:

Die Frage nach dem Typ der Operanden ist nicht bedeutungslos. Handelt es sich um ganzzahlige Typen, wird ein anderes Kompilat erzeugt als bei zwei Dezimalzahlen. Abhängig vom Typ der Operanden werden zwei unterschiedliche Operationen ausgeführt. Der Compiler entscheidet darüber, um welche Operation es sich dabei handelt, denn der »/«-Operator ist überladen.

Insbesondere für die elementaren Datentypen sind die meisten Operatoren überladen. Sie führen, je nach Typ der Operanden, unterschiedliche Operationen aus. Eine der großen Stärken von C# ist, dass dem Entwickler das Instrumentarium in die Hand gegeben wird, im Bedarfsfall Operatoren benutzerdefiniert zu überladen.

7.1.1 Die Syntax der Operatorüberladung 

Um Operatoren in einer Klasse oder einer Struktur zu überladen, stellt C# das Schlüsselwort operator zur Verfügung, das nur in Verbindung mit public static verwendet werden darf. Hinter dem operator-Schlüsselwort wird der Operator angegeben, der überladen werden soll. Die folgende Syntax gilt für binäre Operatoren, die zwei Operanden für ihre Operation benötigen.

Neben den binären gibt es auch unäre Operatoren, die nur einen Operanden verlangen. Stellvertretend seien hier die Operatoren »++« und »--« genannt. Für diese Operatorengruppe ändert sich die Syntax wie folgt:

Wenn Sie eine Klasse um Methoden zur Operatorüberladung erweitern, sollten Sie folgende Punkte berücksichtigen:

Es können nur bereits vordefinierte Operatoren überladen werden. Sie können also keine neuen Operatoren »erfinden«.

Die Operationen von Operatoren auf den systemeigenen Typen können nicht umdefiniert werden.

Die Grundfunktionalität eines Operators bleibt immer erhalten: Ein binärer Operator benötigt immer zwei Operanden, ein unärer immer einen. Die Vorrangregeln können nicht beeinflusst werden.

In der folgenden Tabelle sind alle Operatoren aufgeführt, die in einer Klasse oder Struktur überladen werden dürfen.

Einige Operatoren können nur paarweise überladen werden. Wollen Sie zum Beispiel den Vergleichsoperator »==« überladen, müssen Sie auch den Operator »!=« überladen. Damit erzwingt C# eine konsistente Prüfung auf Übereinstimmung und Nichtübereinstimmung.

Einschränkungen der Operatorüberladung

Nicht alle Operatoren sind überladungsfähig. So können Sie den Zuweisungsoperator »=« nicht überladen. Überladen Sie einen binären Operator, z.B. »+«, wird der Additionszuweisungsoperator »+=« automatisch implizit überladen.

Zu den anderen nichtüberladbaren Operatoren gehören der Punktoperator, der bedingte Operator »?:« sowie die Operatoren new, is, typeof und sizeof. Ebenso wenig überladbar sind die runden Klammern, mit denen eine Typkonvertierung durchgeführt wird. Stattdessen sollten benutzerdefinierte Konvertierungen implementiert werden. Dieses Thema beschäftigt uns weiter unten.

7.1.2 Beispiel einer Operatorüberladung 

Wir wollen uns die Operatorüberladung jetzt an einem Beispiel ansehen. Dazu rufen wir uns die Methode IsBigger der Klasse GeometricObject in Erinnerung:

Mit

können wir zweifelsfrei prüfen, welcher der beiden Kreise der größere oder der kleinere ist. Selbstkritisch müssen wir aber auch feststellen, dass der Ausdruck

eher einer üblichen Vergleichsoperation entspricht. Bisher ist diese Vergleichsoperation jedoch nicht möglich, weil sie für Objekte vom Typ der Basisklasse GeometricObject oder in einer der abgeleiteten Klassen nicht definiert ist.

Um dieses Defizit auszugleichen, wollen wir jetzt den »>=«-Operator so überladen, dass er zur Laufzeit auf zwei Objekte vom Typ GeometricObject angewendet werden kann:

Kompilieren wir die so ergänzte Klassendefinition, werden wir einen Compilerfehler erhalten, weil sich ein GeometricObject-Objekt jetzt nicht mehr eindeutig verhält. Wir werden gezwungen, einen weiteren Vergleichsoperator zu überladen, nämlich den, der die Umkehrung der vorher überladenen Vergleichsfunktion beschreibt.

Nach dem anschließenden, jetzt erfolgreichen Kompilieren können wir mit

alternativ zu der von uns implementierten Methode IsBigger Vergleichsoperationen mit Objekten unserer Klasse ausführen.

7.1.3 Überladungsbeispiele 

Überladen von Gleichheitsoperatoren

In Kapitel 4, Abschnitt 4.7.6, haben Sie erfahren, wie mit der Methode Equals der Klasse Object zwei Referenzen auf Gleichheit untersucht werden können:

Zeigen beide Referenzen auf dasselbe Objekt, liefert die Equals-Methode als Rückgabewert true. Das ist das Standardverhalten dieser Methode. In gleicher Weise arbeitet auch der »==«-Vergleichsoperator. Wir könnten demnach die if-Anweisung auch wie folgt formulieren:

Die Instanzmethode Equals (es gibt auch eine statische Klassenmethode gleichen Namens) ist virtuell definiert und kann von jeder Klasse überschrieben werden, beispielsweise um anstatt eines Referenzvergleichs einen wertbasierten Vergleich der Zustandsdaten von zwei typgleichen Objekten zu erzwingen. Wenn Equals überschrieben wird, sollte auch der Vergleichsoperator der benutzerdefinierten Klasse überschrieben werden, damit die Austauschbarkeit zwischen Equals und dem »==«-Operator weiterhin gewährleistet bleibt.

In der Klasse GeometricObject wird nun die Equals-Methode so überschrieben, dass der Vergleich zweier Objekte nicht mehr anhand der Referenz erfolgt, sondern dazu die Fläche der Objekte ausgewertet wird.

Die Implementierung der beiden operator-Methoden ist denkbar einfach: Es wird nur die in der Klasse überschriebene Methode Equals aufgerufen, welche die eigentliche Arbeit verrichtet.

»true- und false«-Operatoren

Wenn Sie Tabelle 7.1 aufmerksam studiert haben, werden Ihnen vermutlich zwei ungewöhnlich erscheinende, überladungsfähige Operatoren aufgefallen sein: true und false. Diese dienen dazu, Operationen wie beispielsweise

zu ermöglichen. Diese Bedingungsprüfung ist sinnvoll, wenn der Rückgabewert direkt abhängig von einem Feld ist. Soll außerdem auch noch der Negationsoperator berücksichtigt werden, muss auch der »!«-Operator überladen werden.

Die Operatoren true und false gehören ebenfalls zu der Gruppe der Operatoren, die man nur paarweise überladen kann. Die Rückgabe ist ein boolescher Wert. Im folgenden Beispiel wird die Überladung aller drei Operatoren gezeigt. Dazu wird festgelegt, dass ein Objekt dann true zu bewerten ist, wenn der Inhalt des objektspezifischen ungleich der Zahl 0 ist.

Die dem Feld zugewiesene Zahl 8 wird mit

zu der Anzeige

führen. Benutzen wir im Ausdruck den »!«-Operator, kehrt sich die Logik natürlich um und führt zu der Ausgabe:

7.1.4 Benutzerdefinierte Konvertierungen – implizit und explizit 

Stellen Sie sich vor, Sie hätten die Klasse ClassA folgendermaßen definiert:

Zugegeben, die Implementierung ist äußerst trivial, denn der Typ ClassA enthält nur ein int-Feld. Diese Definition könnte dazu verleiten, eine Referenz der Klasse ClassA einer int-Variablen wie folgt zuzuweisen:

Selbstverständlich wird es nur bei einem Versuch bleiben, denn der Compiler stellt eine unzulässige Konvertierung des ClassA-Typs in einen int fest und macht das Unterfangen zunichte.

C# bietet uns die Möglichkeit, bestimmte Typkonvertierungen zu gestatten. Angenommen unser Ziel sei, das Codefragment tatsächlich einwandfrei zu kompilieren. Dazu müssen wir die Klasse um die Definition einer benutzerdefinierten Konvertierung wie folgt erweitern:

Sehen wir uns den Methodenkopf genauer an. Im Vergleich zu einer Methode, die einen Operator überlädt, ist die Definition der Methode zur Typkonvertierung um das neue Schlüsselwort implicit ergänzt. Den Schlüsselwörtern implicit operator folgt der Datentyp, in den implizit konvertiert wird. In unserem Beispiel ist es int. Der Parameter definiert den Typ, der konvertiert werden soll.

Die allgemeine Syntax der impliziten benutzerdefinierten Typkonvertierung lautet:

Die Aussage in unserem Beispiel ist also die folgende: Konvertiere ein Objekt vom Typ ClassA implizit in einen int.

Benutzerdefinierte Konvertierungen liefern ein Ergebnis: Es ist genau von dem Typ, der hinter operator angegeben wird. Im Anweisungsblock der Konvertierungsmethode muss deshalb ein return-Statement gefolgt vom entsprechenden Rückgabewert angegeben werden – in unserem Fall der Inhalt des Feldes MyValue des Objekts, dessen Referenz die Methode im Parameter obj empfängt.

Weil ein int vom System implizit in einen long-Typ konvertiert wird, wird jetzt auch das folgende Codefragment fehlerfrei kompiliert:

Eine implizite Konvertierung kann auch zwischen Klassen erzwungen werden, die sich auf keiner Vererbungslinie befinden. Im folgenden Beispielprogramm wird das gezeigt. Es definiert die beiden Klassen ClassA und ClassB. In ClassA wird eine implizite Konvertierung in ClassB ermöglicht.

Eine implizite Konvertierung bietet sich an, wenn bei einer Konvertierung keine Daten verloren gehen. Nehmen wir nun an, die Klasse ClassA sei etwas anspruchsvoller:

Wir wollen wieder sicherstellen, die Referenz auf ein ClassA-Objekt in einen Integer zu konvertieren. Es kann uns nichts davon abhalten, weiterhin eine implizite benutzerdefinierte Konvertierung anzubieten. Tatsache ist aber, dass uns bei der Typumwandlung Informationen verloren gehen, auch wenn diese vom empfangenden Element nicht benötigt werden – hier ist es das Feld vom Typ string. Legen Sie Wert auf eine stilistisch saubere Programmierung, sollten Sie deshalb eine explizite Konvertierung vorschreiben. Sie vermeiden dadurch außerdem, dass eine implizite Konvertierung automatisch ausgeführt wird, ohne dass der Aufrufer sie gewünscht hat.

Um eine benutzerdefinierte, explizite Typumwandlung zu implementieren, muss das Schlüsselwort explicit in der Methodensignatur angegeben werden. Die allgemeine Syntax ähnelt der impliziten benutzerdefinierten Konvertierung:

Sehen wir uns dazu das vollständige Beispiel an:

ClassA beschreibt nun sogar zwei explizite Konvertierungen: in einen int und in einen string. Programmcode, der ein ClassA-Objekt einem int zuweisen möchte, würde jetzt zu einer expliziten Konvertierung gezwungen, z.B.:

Analog lässt sich mit der Anweisung

eine Referenz vom Typ ClassA auch einer string-Variablen zuweisen.

Implizite und explizite Konvertierung von Referenztypen

In den beiden vorhergehenden Abschnitten war der Zieldatentyp ein einfacher Datentyp. Auf dieselbe Art und Weise kann auch in einen Referenztyp konvertiert werden. Nehmen wir an, es wären die beiden Klassen ClassA und ClassB wie folgt definiert:

Unser Ziel sei uns nun, die implizite Konvertierung eines ClassA-Objekts in ein ClassB-Objekt und umgekehrt zu erreichen, um beispielsweise den folgenden Code zu ermöglichen:

Würden die beiden Klassen in einer Vererbungsbeziehung stehen und ClassA aus ClassB abgeleitet, wäre die Zuweisung kein Problem, da eine Subklassenreferenz implizit in eine Basisklassenreferenz konvertiert wird. Wie wir wissen, können wir auch die Referenz eines Basisklassenobjekts einer Subklassenreferenz zuweisen, müssen aber die Basisklassenreferenz dabei explizit konvertieren. Der passende Konvertierungsoperator wird uns aufgrund der Vererbungsbeziehung automatisch zur Verfügung gestellt. Die Ausgangssituation zwischen ClassA und ClassB ist in unserem Beispiel eine gänzlich andere und zwingt uns zu einer benutzerdefinierten Konvertierung, entweder implizit oder explizit.

Der Zieldatentyp ist nun ClassB, d. h., dass die Konvertierungsfunktion ein Objekt vom Typ ClassB als Rückgabewert liefert. In der Routine wird deshalb ein neues Objekt dieses Typs erzeugt. Man muss sich jetzt noch überlegen, welche gemeinsamen Merkmale beide Klassen aufweisen. In unserem Beispiel handelt es sich nur um das in beiden Klassen deklarierte Feld vom Typ int. Daher wird der Inhalt des Feldes MyValue des ClassA-Objekts dem Feld Value des ClassB-Objekts zugewiesen. Das so initialisierte Objekt wird als Ergebnis der impliziten Konvertierung bereitgestellt.

Die Konvertierung eines ClassA- in ein ClassB-Objekt hat Datenverlust zur Folge. Daher ist es besser, anstelle der impliziten eine explizite Konvertierung vorzuschreiben. Dazu muss nur das Schlüsselwort implicit gegen explicit ausgetauscht werden:

Nun wird die Typumwandlung nur über den Konvertierungsoperator erlaubt, führt aber ansonsten zum gleichen Ergebnis wie eine implizite Konvertierung:

Auf der Buch-CD finden Sie die Beispielprogramme ConvertImplicitDemo und ConvertExplicitDemo, welche die implizite und explizite Konvertierung zeigen.

Überladen benutzerdefinierter Konvertierungsmethoden

Das gleichzeitige Implementieren einer expliziten und einer impliziten Konvertierungsfunktion mit demselben Zieldatentyp ist nicht zulässig. Daher ist der folgende Programmcode falsch:

Gestattet ist jedoch die Koexistenz einer impliziten und einer expliziten Konvertierung, wenn sich die beiden Überladungsmethoden im Zieldatentyp unterscheiden. Im folgenden Codefragment ist in ClassA eine explizite Konvertierung in den Typ long definiert und eine implizite in einen int. Die Klassendefinition wird fehlerfrei kompiliert.